IPAD 1.1 - DNS Troubleshooting Contact: eSoft, Inc. (Makers of TBBS) 15200 E. Girard Ave., Suite 3000 Aurora, CO 80014 (303) 699-6565 Voice (303) 699-6872 Fax (303) 699-8222 BBS support@esoft.com E-Mail ----------------------------------------------------------------------------- IPAD Tech Note #2 DNS Issues 3/14/96 INTRODUCTION ============ The purpose of this tech note is to explain in greater detail the relationship between the DNS server and resolver as well as tools you might use to diagnose common problems. THE DNS SERVER AND RESOLVER =========================== DNS, the Domain Name System, works using a server and a resolver. The server contains information and can find out information it doesn't know from other servers. The resolver is the user-end client that queries a server for specific information. Since domain names are meaningless to TCP/IP, DNS is used to map these names to IP addresses. In this way, the Internet is "humanized" so that people don't need to remember meaningless IP addresses such as 199.45.145.5, and can instead remember an organized name like www.esoft.com. When a user enters www.esoft.com into their web browser, the resolver is the part that first takes over to help determine the corresponding IP address. The resolver "talks" to a known DNS server and says "Who is www.esoft.com?" Once the DNS server receives the resolver's query, it proceeds to ask other servers where it needs to go. First, it will look in it's cache, which is a collection of the most recently requested domain names. If the name can't be found there, the server will ask a root server for the information. While a root server won't tell the IP address for www.esoft.com, it can tell the server requesting that information to go to eSoft's DNS server at 199.45.143.14 to find out. When the DNS server connects to eSoft's name server, it will be told that www.esoft.com maps to the IP address 199.45.143.5. The DNS server will write this information to its cache (incase it's asked again) and will send a message back to the user's resolver, letting it know the correct IP address. Once the resolver has the IP address, it can pass it onto the web browser application, so the browser can make the desired HTTP connection. COMMON PROBLEMS =============== Now that you understand the relationship between the DNS server and resolver, there are a few problems which can arise. Typically a user will be notified "DNS name could not be found!" or "Could not access www.esoft.com!" Since the application relays this message, it can appear inconsistent among different applications while there can be different explanations for the problem. Resolver Timeout ---------------- The relationship between a DNS resolver and server are not really a transaction in the sense that you might think it to be. That is, the familiar "pause" you experience when typing a domain name in at a web browser or telnet prompt is NOT the resolver connecting to the server and waiting for a response. Instead, the resolver sends its message to the server and waits for the server to send its message. When the resolver's timer expires, it will report back to the application that the domain name's IP address couldn't be found. HOWEVER, since it's the server's responsibility to notify the resolver that it can or can't find the information, a very real possibility is that the server is STILL looking for the DNS information when the resolver times out and tells the application that it doesn't know what the IP address is. While many resolvers time out after 15 seconds, depending on the situation on the Internet, it can take a server longer to find that information, sometimes up to 30 or 45 seconds. In fact, if you re-load the domain name afterwards, chances are good that the server will have the information and return it to the resolver from its cache. As a result, the whole process of finding a domain name from the perspective of resolver-server interaction is akin to a deaf child knocking on the front door. The child, or resolver, will knock three times, and if the door doesn't open, it will walk away. It won't be able to hear the person inside shouting "Hey, I'm working on it!" to stick around. You can see this problem in action if you perform a lookup on a name, receive a timeout, and look at the DNS cache. For example, if you performed a recursive lookup using the IPAD's NSlookup command: Cmd> nslookup -rec esoft.com (the -rec means that the specified or, as in this case, assumed DNS server should do the looking - not the nslookup program) and received the following: Non-authoritative response: Server reported No type "ANY" RR records for esoft.com. Server address srtt mdev timeout queries responses timeouts 199.45.143.14 1543 0 5000 3 0 3 This means that the nslookup, acting as a resolver, queried the name server at 199.45.143.14 three times and didn't receive a response. However, it might mean that it took longer for the server to find that information. If you looked at the memory portion of the DNS cache using the command: Cmd> domain cache list You would see information for esoft.com placed at the top of the list. If you issued the same nslookup command again, you would receive the information for esoft.com. Sever can't be reached ---------------------- Another problem can be that an authoritative name server for the domain name cannot be reached. This is typically due to a downed route or name server machine. Your server can't reach the site so it has no choice but to tell the resolver that it can't find the domain name. To see if this is the case perform a traceroute to the name server. First, find out the domain name or IP address for the name server that is authoritative for the domain you're looking for. Do this by asking a root server, such as in the following example: Cmd> nslookup esoft.com a.root-servers.net You would receive the following information: Non-authoritative response: esoft.com. 172800 IN NS NS1.esoft.com. esoft.com. 172800 IN NS NS2.esoft.com. Authority resource records: esoft.com. 172800 IN NS NS1.esoft.com. esoft.com. 172800 IN NS NS2.esoft.com. Additional information resource records: NS1.esoft.com. 172800 IN A 199.45.143.14 NS2.esoft.com. 172800 IN A 199.45.143.150 From this information, you can see that the name servers ns1.esoft.com and ns2.esoft.com, with the IP addresses of 199.45.143.14 and 199.45.143.150, respectively, are authoritative for the domain esoft.com. Since these are the only two machines that can tell you what you need to know, if you can't reach them, you'll never be able to get domain name information from them. Use the traceroute command to see how far you can make it. The following example shows a break at the IP address 199.45.143.2 which probably means a router is down or has "forgotten" it's next hop: Cmd> tracroute ns1.esoft.com 1: 132.198.103.16 wat2-gw.uvm.edu. (2 ms) (2 ms) (2 ms) 2: 132.198.200.66 uvm-gw.uvm.edu. (2 ms) (2 ms) (2 ms) 3: 199.94.204.77 bbn-4.bbnplanet.net. (18 ms) (27 ms) (17 ms) 4: 199.94.205.1 bbn-1.bbnplanet.net. (19 ms) (20 ms) (202 ms) 5: 192.233.149.202 mit1-3.bbnplanet.net. (19 ms) (22 ms) (19 ms) 6: 192.233.33.11 cpe1-fddi-0.boston.mci.net. (27 ms) (40 ms) (32 ms) 7: 204.70.20.5 border1-hssi1-0.Boston.mci.net. (151 ms) (98 ms) (20 ms) 8: 204.70.2.33 core-fddi-0.Boston.mci.net. (24 ms) (29 ms) (66 ms) 9: 204.70.1.1 core-hssi-2.NewYork.mci.net. (48 ms) (39 ms) (35 ms) 10: 204.70.3.18 border2-fddi-0.NewYork.mci.net. (38 ms) (40 ms) (43 ms) 11: 204.70.45.6 sprint-nap.NewYork.mci.net. (39 ms) (43 ms) (53 ms) 12: 192.157.69.9 sl-pen-2-F4/0.sprintlink.net. (78 ms) (89 ms) (71 ms) 13: 144.228.10.38 sl-chi-3-H2/0-T3.sprintlink.net. (133 ms) (67 ms) (88 ms) 14: 144.228.50.15 sl-chi-15-F0/0.sprintlink.net. (122 ms) (87 ms) (115 ms) 15: 144.228.10.70 sl-kc-2-H3/0-T3.sprintlink.net. (78 ms) (99 ms) (87 ms) 16: 144.224.20.1 (100 ms) (134 ms) (135 ms) 17: 144.228.10.82 sl-che-2-H2/0-T3.sprintlink.net. (229 ms) (179 ms) * 18: *** *** *** Host Unreachable! On this route, the link appears to be broken after 144.228.10.82, so ns1.esoft.com can't be reached. Address Doesn't Exist --------------------- The final case is one in which the domain name simply doesn't exist. You can tell this both from the resolver's response and looking at the cache. For example, if you perform an nslookup on the domain thisdoesntexist.com, you will get back: Cmd> ns -rec thisdoesntexist.com Authoritative response: Server reported No type "ANY" RR records for thisdoesntexist.com. Authority resource records: com. 86400 IN SOA A.ROOT-SERVERS.NET. HOSTMASTER.INTERNIC.NET. 1996031300 10800 900 604800 86400 The root server reports back to the connected server that thedomain doesn't exist. Additionally, if you look in the server's cache using the domain cache list command: Cmd> do ca li thisdoesntexist.com. 86396 IN ANY [Negative Response Memory] . . . You will see the [Negative Response Memory] noted, which means that the server was told by the root "I don't know who this domain is." ----------------------------------------------------------------------------- - END - IPAD0002.TXT Revised 3/96 Copyright (C) 1996 eSoft, Inc., All Rights Reserved. Permission granted to distribute this file in its entirety, without modification, to any interested party. Any other use requires the written permission of eSoft, Inc. IMPORTANT: The information herein is subject to change without notice. Please call or write to confirm factual information of importance to you or your organization.